Method and apparatus for use in a communications network

ABSTRACT

A method of enabling redundancy for a Home Subscriber Service (HSS) of an IP Multimedia Subsystem (IMS) is provided. Redundancy is provided by a plurality of HSS instances. Where a client node of the IMS requires details of an HSS, the client node is provided with details of a proxy HSS representing the HSS instances. The client node uses the details to send a subsequent request directed to the proxy HSS. The proxy HSS selects an appropriate one of the HSS instances to handle the request received at the proxy HSS from the client node. The proxy HSS forwards the request to the selected HSS instance for handling.

TECHNICAL FIELD

The present invention relates to a method and apparatus for use in acommunications network, for example a Universal MobileTelecommunications System having an IP Multimedia Subsystem.

BACKGROUND

IP Multimedia services provide a dynamic combination of voice, video,messaging, data, etc. within the same session. By growing the number ofbasic applications and the media which it is possible to combine, thenumber of services offered to the end users will grow, and theinter-personal communication experience will be enriched. This will leadto a new generation of personalised, rich multimedia communicationservices, including so-called “combinational IP Multimedia” services.

The UMTS (Universal Mobile Telecommunications System) is a thirdgeneration wireless system designed to provide higher data rates andenhanced services to subscribers. UMTS is a successor to the GlobalSystem for Mobile Communications (GSM), with an important evolutionarystep between GSM and UMTS being the General Packet Radio Service (GPRS).GPRS introduces packet switching into the GSM core network and allowsdirect access to packet data networks (PDNs). This enables high-datarate packets switch transmissions well beyond the 64 kbps limit of ISDNthrough the GSM call network, which is a necessity for UMTS datatransmission rates of up to 2 Mbps. UMTS is standardised by the 3rdGeneration Partnership Project (3GPP) which is a conglomeration ofregional standards bodies such as the European TelecommunicationStandards Institute (ETSI), the Association of Radio Industry Businesses(ARIB) and others. See 3GPP TS 23.002 for more details.

The UMTS architecture includes a subsystem known as the IP MultimediaSubsystem (IMS) for supporting traditional telephony as well as new IPmultimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides keyfeatures to enrich the end-user person-to-person communicationexperience through the use of standardised IMS Service Enablers, whichfacilitate new rich person-to-person (client-to-client) communicationservices as well as person-to-content (client-to-server) services overIP-based networks. The IMS is able to connect to both PSTN/ISDN (PublicSwitched Telephone Network/Integrated Services Digital Network) as wellas the Internet.

The IMS makes use of the Session Initiation Protocol (SIP) to set up andcontrol calls or sessions between user terminals (or user terminals andapplication servers). The Session Description Protocol (SDP), carried bySIP signalling, is used to describe and negotiate the media componentsof the session. Whilst SIP was created as a user-to-user protocol, IMSallows operators and service providers to control user access toservices and to charge users accordingly. The 3GPP has chosen SIP forsignalling between a User Equipment (UE) and the IMS as well as betweenthe components within the IMS.

Specific details of the operation of the UMTS communications network andof the various components within such a network can be found from theTechnical Specifications for UMTS that are available fromhttp://www.3gpp.org. Further details of the use of SIP within UMTS canbe found from the 3GPP Technical Specification TS 24.228 V5.8.0(2004-03).

FIG. 1 of the accompanying drawings illustrates schematically how theIMS fits into the mobile network architecture in the case of a GPRS/PSaccess network (IMS can of course operate over other access networks).Call/Session Control Functions (CSCFs) operate as SIP proxies within theIMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF(P-CSCF) which is the first point of contact within the IMS for a SIPterminal; the Serving CSCF (S-CSCF) which provides services to the userthat the user is subscribed to; and the Interrogating CSCF (I-CSCF)whose role is to identify the correct S-CSCF and to forward to thatS-CSCF a request received from a SIP terminal via a P-CSCF.

A user registers with the IMS using the specified SIP REGISTER method.This is a mechanism for attaching to the IMS and announcing to the IMSthe address at which a SIP user identity can be reached. In 3GPP, when aSIP terminal performs a registration, the IMS authenticates the user,and allocates a S-CSCF to that user from the set of available S-CSCFs.Whilst the criterion for allocating S-CSCFs is not specified by 3GPP,these may include load sharing and service requirements. It is notedthat the allocation of an S-CSCF is key to controlling (and chargingfor) user access to IMS-based services. Operators may provide amechanism for preventing direct user-to-user SIP sessions which wouldotherwise bypass the S-CSCF.

During the registration process, it is the responsibility of the I-CSCFto select a S-CSCF if a S-CSCF is not already selected. The I-CSCFreceives the required S-CSCF capabilities from the home network's HomeSubscriber Server (HSS), and selects an appropriate S-CSCF based on thereceived capabilities. (It is noted that S-CSCF allocation is alsocarried out for a user by the I-CSCF in the case where the user iscalled by another party, and the user is not currently allocated anS-CSCF.) When a registered user subsequently sends a session request tothe IMS, the P-CSCF is able to forward the request to the selectedS-CSCF based on information received from the S-CSCF during theregistration process.

Within the IMS service network, Application Servers (ASs) are providedfor implementing IMS service functionality. Application Servers provideservices to end-users in an IMS system, and may be connected either asend-points over the 3GPP defined Mr interface, or “linked in” by anS-CSCF over the 3GPP defined ISC interface. In the latter case, InitialFilter Criteria (IFC) are used by an S-CSCF to determine whichApplications Servers should be “linked in” during a SIP Sessionestablishment. Different IFCs may be applied to different call cases.The IFCs are received by the S-CSCF from an HSS during the IMSregistration procedure as part of a user's User Profile. CertainApplication Servers will perform actions dependent upon subscriberidentities (either the called or calling subscriber, whichever is“owned” by the network controlling the Application Server). For example,in the case of call forwarding, the appropriate (terminating)application server will determine the new terminating party to which acall to a given subscriber will be forwarded. In the case that an IFCindicates that a SIP message received at the S-CSCF should be forwardedto a particular SIP AS, that AS is added into the message path. Once theSIP message is returned by the AS to the S-CSCF, it is forwarded ontowards its final destination, or forwarded to another AS if this isindicated in the IFCs.

As mentioned above, in an IMS network, the HSS is mainly in charge ofstoring the subscriber data. The HSS inter-works with other nodes(referred to herein generally as “HSS clients”) by means of the Diameterprotocol (RFC 3588). Examples of such HSS client are the I-CSCF, S-CSCF,AP (Aggregation Proxy) and AS (Application Server).

The general intention is that the HSS is a central database for adomain. However, some networks have more users than can be handled by asingle HSS, and these networks are therefore provided with more than oneHSS. Networks with more than one HSS also contain a SubscriptionLocation Function (SLF). Nodes that need to query an HSS about aparticular user first query the SLF, which returns the address of theHSS handling the user. The SLF essentially acts as a Diameter redirectagent.

However, the standalone scenario, with only one HSS and no SLF deployedin the network, is very common in current deployments and must also beconsidered.

Diameter routing logic involving the HSS can be found in 3GPP TS 29.228.Although the following extracts are focused on CSCF nodes, they applyequally to any other type of HSS client.

“If an I-CSCF or S-CSCF knows the address/name of the HSS for a certainuser, both the Destination-Realm and Destination-Host AVPs (AttributeValue Pairs) shall be present in the request. Otherwise, only theDestination-Realm AVP shall be present and the command shall be routedto the next Diameter node, e.g. the SLF, based on the Diameter routingtable in the client.

Once the redirector function (SLF) has returned the address or thedestination HSS (using Redirect-Host AVP), the redirected request to theHSS shall include both Destination-Realm and Destination-Host AVPs.

The S-CSCF stores the address of the HSS for each user, after a firstrequest sent to the redirector function.

Requests initiated by the HSS towards an S-CSCF shall include bothDestination-Host and Destination-Realm AVPs. The HSS obtains theDestination-Host AVP to use in requests towards an S-CSCF, from theOrigin-Host AVP received in previous requests from the S-CSCF.Consequently, the Destination-Host AVP is declared as mandatory in theABNF for all requests initiated by the HSS.

Destination-Realm AVP is declared as mandatory in the ABNF for allrequests.”

As appreciated by the applicant, one issue that is not specificallyaddressed in the 3GPP standard is that of a redundancy solution for theHSS: in a real deployment the user data might be stored in more than oneHSS (for instance in a hot/standby configuration, which is the onecurrently available in TSP, load sharing, and so on). A mechanism thatwould allow an HSS client to learn the right HSS address is notspecified in the 3GPP standard. The IETF Diameter document (RFC3588)provides a redundancy solution for “Diameter agents” but not fordestination hosts. For example, in 3GPP IMS a Subscription LocationFunction (SLF) is a “Diameter redirect agent”, and a Home SubscriberServer HSS is a destination host.

It is desirable to address this issue.

SUMMARY

According to a first aspect of the present invention there is provided amethod of enabling redundancy for a Home Subscriber Service, HSS, of anIP Multimedia Subsystem, IMS, with redundancy being provided by aplurality of HSS instances, and the method comprising: where a clientnode of the IMS requires details of an HSS, arranging for the clientnode to be provided with details of a proxy HSS representing the HSSinstances; arranging for the proxy HSS to select an appropriate one ofthe HSS instances to handle a request received at the proxy HSS from theclient node; and arranging for the proxy HSS to forward the request tothe selected HSS instance for handling.

The method may comprise, where a Subscription Location Function, SLF, isprovided in the IMS, arranging for the SLF to provide the client nodewith details of the proxy HSS.

The method may comprise, where a Subscription Location Function, SLF, isnot provided in the IMS, arranging for the proxy HSS itself to providethe client node with details of the proxy HSS.

The Diameter protocol may be used for communication between the clientnode and the proxy HSS.

The method may comprise changing a destination host Attribute Value Pairin the received request based on the selection.

Redundancy of the proxy HSS may also be provided, by having a pluralityof proxy HSS instances, with redundancy towards the proxy HSS instancesbeing handled by standard Diameter protocol mechanisms.

At least some of the HSS instances may be different respective frontends to a database.

The method may comprise maintaining information at the proxy HSS for usein performing the selection.

The information may comprise at least one of: information relating torespective loads being experienced by the HSS instances; respectiveavailabilities of the HSS instances; and respective statuses of the HSSinstances.

Where the database is distributed across a plurality of sites, theinformation may comprise geographic information relating to the sites.

The method may comprise monitoring the state of each HSS instance foruse in performing the selection.

The method may comprise monitoring the state by using Diameter messages.

The method may comprise monitoring the state by using DWR/DWA messages.

The method may comprise performing the selection based on at least oneof geographical location, availability, load, and response time.

The proxy HSS may be a node of the IMS.

The proxy HSS may be a Diameter proxy agent.

The client node may be a Diameter client.

The client node may comprise at least one of: an Interrogating CallSession Control Function of the IMS; a Serving Call Session ControlFunction of the IMS; an Aggregation Proxy of the IMS; and an ApplicationServer of the IMS.

The method may be performed at the proxy HSS.

The HSS may be replaced by a destination host of the IMS other than aHSS.

According to a second aspect of the present invention there is providedan apparatus for enabling redundancy for a Home Subscriber Service, HSS,of an IP Multimedia Subsystem, IMS, with redundancy being provided by aplurality of HSS instances, and the apparatus comprising: means forarranging, where a client node of the IMS requires details of an HSS,for the client node to be provided with details of a proxy HSSrepresenting the HSS instances; means for arranging for the proxy HSS toselect an appropriate one of the HSS instances to handle a requestreceived at the proxy HSS from the client node; and means for arrangingfor the proxy HSS to forward the request to the selected HSS instancefor handling.

The apparatus may comprise the proxy HSS.

According to another aspect of the present invention there is provided amethod of enabling redundancy for a destination host of an IP MultimediaSubsystem, IMS, with redundancy being provided by a plurality ofdestination host instances, and the method comprising: where a clientnode of the IMS requires details of a destination host, arranging forthe client node to be provided with details of a proxy destination hostrepresenting the destination host instances; arranging for the proxydestination host to select an appropriate one of the destination hostinstances to handle a request received at the proxy destination hostfrom the client node; and arranging for the proxy destination host toforward the request to the selected destination host instance forhandling. The proxy destination host may be a Diameter proxy agent.Apparatus comprising means for performing these method steps is alsoprovided.

According to another aspect of the present invention there is provided amethod of enabling redundancy for a protocol server of a communicationsnetwork, with redundancy being provided by a plurality of protocolserver instances, and the method comprising: where a protocol clientrequires details of a protocol server, arranging for the protocol clientto be provided with details of a proxy protocol server representing theprotocol server instances; arranging for the proxy protocol server toselect an appropriate one of the protocol server instances to handle arequest received at the proxy protocol server from the protocol client;and arranging for the proxy protocol server to forward the request tothe selected protocol server instance for handling. The protocol may bethe Diameter protocol. The proxy protocol server may be a Diameter proxyagent. Apparatus comprising means for performing these method steps isalso provided.

According to a third aspect of the present invention there is provided aprogram for controlling an apparatus to perform a method according tothe first aspect of the present invention or which, when loaded into anapparatus, causes the apparatus to become an apparatus according to thesecond aspect of the present invention. The program may be carried on acarrier medium. The carrier medium may be a storage medium. The carriermedium may be a transmission medium.

According to a fourth aspect of the present invention there is providedan apparatus programmed by a program according to the third aspect ofthe present invention.

According to a fifth aspect of the present invention there is provided astorage medium containing a program according to the third aspect of thepresent invention.

An embodiment of the present invention has at least one of the followingadvantages:

As there is one logical HSS deployed in the network, it is possible forany third party vendor product to take advantage of the HSS redundancysolution (which is not standardized). The interface between the HSSclient and the Diameter proxy application is based on pure Diameterstandard mechanisms.

No changes in the IP routing tables are needed, and, advantageously,client nodes only need to be configured with the destination address ofthe Proxy apparatus in an embodiment of the present invention, which isarranged for replacing the destination address received from a clientnode, which addresses the Proxy apparatus, into a destination address ofthe server selected therein.

The distribution logic to the destination peer can be configureddepending on the scenario: it can be based on load sharing, userlocation . . . .

A method and apparatus embodying the present invention are valid forboth, current “monolithic” HSS and the tiered (layered) HSSarchitectures. It does not matter whether the final destination is amonolithic HSS or a Front End.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1, discussed hereinbefore, illustrates schematically theintegration of an IP Multimedia Subsystem into a 3G mobilecommunications system;

FIG. 2 is a schematic flowchart illustrating steps performed in anembodiment of the present invention;

FIG. 3 is a schematic block diagram showing parts of apparatus embodyingthe present invention for performing the method of FIG. 2;

FIG. 4 is a schematic block diagram showing the use of multiple proxyHSSs (Diameter Proxies) in a system embodying the present invention; and

FIG. 5 is a schematic block diagram showing parts of an example proxyHSS with information being monitored for use in selecting an HSSinstance (HSS front end).

DETAILED DESCRIPTION

It has been mentioned above that the problem of a redundancy solutionfor the HSS is not specifically addressed in the 3GPP standard. Before adetailed description of an embodiment of the present invention, thefollowing three possible solutions that would address this redundancyproblem will now be described in turn, each having some limitations asset out below: (a) route all the traffic through the SLF; (b) rely onDiameter protocol standard procedures; and (c) IP layer based solutions.This will be followed by a description of: (d) other mechanisms forobtaining the redundant node; and then (e) a solution according to anembodiment of the present invention.

(a) Route all the Traffic Through SLF

The SLF could monitor the HSS's state (this is currently done inEricsson's IPWorks product, for the AS DNS functionality, where SNMP andICMP are used for this purpose) and only the “active”/“preferred” onewould be included in the responses. All the traffic towards the HSSshould be routed through the SLF.

However, according to the standard it is not mandatory for an HSS clientto poll the SLF whenever a message has to be sent to HSS. Some examplesthat can be found in current implementations are:

-   -   The S-CSCF stores the HSS “destination host” when it is received        from SLF the first time it is contacted. From that moment on,        and for the same user, that address could be kept. No extra        polls are needed.    -   The HSS destination host can also be sent from the I-CSCF to the        S-CSCF by means of a proprietary mechanism (embedded in the SIP        REGISTER message). In this way the S-CSCF does not need to        retrieve any information from the SLF, since the I-CSCF has        received it from the SLF and passed on to the S-CSCF. This        implementation is used in Ericsson's CSCF.

Moreover, current deployments do not include an SLF when the number ofsubscribers is relatively small; this means that the “single HSSscenario” must also be considered.

(b) Rely on Diameter Protocol Standard Procedures

It is not possible to rely on pure standard Diameter mechanisms (seechapter 5.5.4 of RFC 3588) since routing and failover mechanisms areapplicable only for scenarios with Diameter Agents in charge of routingthe corresponding Diameter application-based messages. In this sense,the failover mechanism provides an alternate way of reaching a givenDestination-Host, by using an alternate Diameter agent. If thedestination host as such is down, there is no mechanism specified in theRFC. That would be another case.

A Diameter Agent is a Diameter node that provides relay, proxy, redirector translation services (performs protocol translation between Diameterand another AAA protocol). In other words, they are used for routingDiameter messages to the final destination (specified by the destinationhost).

(c) IP Layer Based Solutions

Another approach would be to rely on the IP layer: if the redundantnodes shared the same IP address (this would work for hot/standbyredundancy solutions; only the “active” node would own the shared IPaddress) it would be possible to execute the failover with no impact inthe applications. This alternative is currently offered by TSP, and itcan also be found in other commercial platforms (such as for instanceMotorola's AdvancedTCA Communication Server; Sun clusters also includethis feature in many products), but it has several drawbacks:

-   -   Having an IP that moves from one site to another implies that        the host IP part of the routing tables will require some updates        in case of node failure (OSPF could be used for this purpose).        If the backbone is composed of many routers the traffic routing        to the proper destination will not be secured until the complete        backbone convergence is achieved. Some backbone tuning might be        required in each installation.    -   As the backbone is usually shared among different solutions        changes in it might affect other solutions. Thus some operators        may not agree on having such tuning done. Besides the deployment        cost will increase exponentially. This is perceived as non        secure.

(d) Other Mechanisms for Obtaining the Redundant Node

The redundant node could be statically configured in a table. For everypossible HSS Destination-Host in the network it is stated itscorresponding secondary (redundant) one. The HSS client could thenmonitor the HSS's state, and when the primary HSS fails, then it wouldsend the Diameter queries to the configured secondary HSS. A drawback ofthis alternative is that HSS redundancy will only work in a scenariowhere all HSS clients in the network (CSCF, Application Servers, AAAserver, BSF, etc.) implement this mechanism.

Alternatively, a new AVP conveying information about the redundant nodescould be added in the SLF responses. This is now under investigation inIETF DIME working group. A drawback of this solution is that these AVPare optional (in order to provide backwards compatibility) and thereforeit is not possible to ensure that the client will make use of it.Moreover, SLF is needed in order to provide this information and it isnot possible to route the message based on other considerations (userlocation, load balancing, and so on).

(e) An Embodiment of the Present Invention

In an embodiment of the present invention an enhanced Diameter proxy isintroduced in order to provide a single logical HSS in the network.Further details will be provided below, but in brief:

-   -   Each HSS client can be configured with a single HSS Destination        host, and no SLF would then needed (although an embodiment of        the present invention can also be used where an SLF is in        operation).    -   The access point to the single logical HSS could comprise one or        several enhanced Diameter proxies, with each Diameter message        sent from the HSS client being received in one of these proxies.        From the HSS client side, the Diameter proxies can be configured        like in the standard Diameter interface.    -   To provide redundancy and to scale the traffic processing        capacity, there could be several proxies. Redundancy towards the        proxies can be achieved with Diameter standard procedures (see        RFC 3588, chapter 5.5.4).    -   The enhanced Diameter proxy would provide mechanisms to find out        what is the most appropriate Diameter peer to process the        Diameter message. These peers can be HSS Front Ends (FEs)        accessing a database that contains the user data, or monolithic        HSSs keeping both the HSS application logic and the user data.        These mechanisms consider the HSS monolithic of FE availability,        the geographical location of the user data as well as manage the        load distribution towards the Diameter peers.

An embodiment of the present invention will now be described in moredetail with reference to FIGS. 2 and 3. FIG. 2 is a schematic flowchartillustrating steps performed in an embodiment of the present invention,while FIG. 3 is a schematic block diagram showing parts of apparatusembodying the present invention.

FIG. 2 shows an HSS client 10 and an SLF 30, which have been describedpreviously. An HSS in this example is provided a degree of redundancy bycomprising first and second HSS instances 40. Finally, a proxy HSS 20 isalso provided, whose function will become apparent from the descriptionbelow.

In response to a request by the HSS Client 10 for details (e.g. a“Destination Host AVP”) of an HSS relating to a particular user, in stepS1 details of the proxy HSS 20 are provided to the HSS client 10, eitherfrom the SLF 30 (if there is one) or (e.g, if there is not a SLF) areconfigured beforehand at the HSS client 10, or are provided from theproxy HSS 20 itself. Advantageously, every HSS client 10 is configuredwith a single HSS Destination Host addressing the proxy HSS 20, whichprovides a simplified configuration of clients and, at the same time,allows to dispense with the need of a SLF. The details of the proxy HSS20 are received by the HSS client 10 in step S2.

In step S3 the HSS client 10 sends a Request to the proxy HSS 20, usingthe details received in step S2, which is received in step S4 by theproxy HSS 20.

In step S5 the proxy HSS 20 performs a selection process to determinewhich of the first and second HSS instances 40 should be chosen tohandle the Request; examples of possible criteria to be used in theselection process are set out further below.

Having made the selection of an appropriate HSS instance 40 in step S5,the Destination Host AVP received from the HSS client 10 is replaced instep S5 a with the Destination Host AVP of the selected HSS instance 40.The Request is then forwarded in step S6 by the proxy HSS 20 to theselected HSS instance 40, which is received and processed in step S7 bythe selected HSS instance 40.

When the Request has been processed, a Response is sent from theselected HSS instance 40 to the proxy HSS 20 and received by the proxyHSS 20 in step S9. In step S10 the Response is forwarded by the proxyHSS 20 to the HSS client 10, and received by the HSS client 10 in stepS11.

Parts of the proxy HSS 20, SLF 30 and HSS instances 40 for performingthe steps of FIG. 2 are illustrated schematically in FIG. 3, with partsP1 and P4 to P10 of FIG. 3 being adapted to perform the steps S1 and S4to S10 respectively of FIG. 2.

It is possible to use a Diameter proxy agent (e.g. proxy HSS),inter-connecting all the nodes, at Diameter level. With this option nochanges are needed in current client nodes, since all the logic can becentralized in the proxy, which replaces the “Destination Host AVP”received from clients (e.g. 10) that addresses the proxy 20 with the“Destination Host AVP” of the HSS instance selected therein, and that isusable to address to it a message received from a client.

Although extra processing and latency is introduced by the proxy, on theother hand queries from the HSS clients to the SLF can be removed, andthe processing power and delays that that implies. Further, the HSSclients only need to be configured with an address of the Proxy HSS 20,and not of individual HSS instances. The clients then use said address(e.g. as “Destination Host AVP” if DIAMETER protocol is used) forsending messages and requests that need to be processed by a HSSinstance, that will make these messages and requests to be automaticallyrouted towards the Proxy HSS.

It is possible to duplicate the proxy. Standard procedures for failoverand link monitoring (see RFC 3588) can be used for this. FIG. 4illustrates an architecture with multiple Diameter proxies 20.

Diameter messages originating in the HSS clients have the samedestination host, as if there was a single HSS (no SLF) deployed in thenetwork, which is the address of the Proxy HSS 20.

The method and Proxy of the invention are usable, both: in monolithicand tiered architectures. In short, a HSS instance according to amonolithic architecture comprises the processing means and applicationlogic, so as to process signaling to be exchanged with HSS clients, aswell as storage means comprising the necessary data (e.g. subscriberdynamic and static information) for accomplishing with said processing.In turn, a HSS “tiered” architecture comprises a plurality of HSSfront-ends (FE), comprising the processing means and application logic,and a (physical or logical) centralized database DB that stores all thenecessary data that can need any HSS FE for accomplishing theirprocessing.

In the case of HSS Front Ends that access a Subscriber Data Base (DB),when this DB is distributed in two or more sites, the proxy can keepinformation about what is the most appropriate Front End (FE) or groupof Front Ends, based on geographical data distribution, to serve eachuser.

The enhanced Diameter proxy application can monitor the state of theDiameter peers that can handle the message for a given user (these peerscould be either monolithic HSS or Front Ends with access to a databasethat contains the user data). In case of redundancy, at least twoDiameter peers (e.g. HSS instances) should be able to manage each user.The mechanism used in the Diameter proxies for monitoring theterminating peers could be either the same one included in the Diameterstandard (DWR/DWA messages) or a different one.

The proxy could distribute the traffic between the different Diameterpeers that are able to handle the operation, for example based ongeographical location and availability. This distribution can be basedon existing balancing mechanism such as server load, response time,round robin, etc.

These concepts are illustrated in FIG. 5.

Once a suitable terminating node has been selected, the destination hostAVP received from the HSS client (i.e. the HSS Diameter URI thatidentifies the single logical HSS) is replaced according to the selectedDiameter peer, and the Diameter message sent to it.

When an answer is received from the terminating node, it is desirable tokeep the Diameter host ID consistent (that is, the answer should comefrom the Destination-Host used in the request). The internalarchitecture of this single logical HSS is transparent to the HSSclients, i.e. the proxy is not required to provide to the HSS client thereal Diameter URI of the selected destination host.

Requests from the HSS can also be proxied. The HSS-Diameter proxyinterface allows redundancy in both directions (the HSS clientDiameterURI can be stored in the HSS/FE according to 3GPP standardprocedures).

Although the present invention has thus far been described mainly inrelation to an HSS client and an HSS, an embodiment of the presentinvention is applicable more generally. In a general sense, anembodiment of the present invention introduces a “Diameter proxy agent”(DPA) (usable in, but not limited to, an IMS architecture) between any“Diameter client” (e.g. Call Session Control function CSCF orApplication Server AS) and any “destination host” (e.g. HSS).

The DPA acts as a standard proxy agent from the client's side, and isenhanced with regard to the destination host's side. The DPA may receivea request from a client containing a “DestinationHost” AVP. The DPAtranslates the (fictitious) “DestinationHost” AVP received from a clientinto an identifier usable to route the request towards the final HSS,which is selected by it according to “availability information”. The DPAthus stores a table comprising (fictitious) “DestinationHost” AVPs thatcan be received from clients, which routes to the DPA, and thecorresponding lists of real “DestinationHost” AVPs identifiers of thereal HSSs that can be selected. Availability information per real HSS,which can be dynamically updated, as well as information aboutgeographic location of HSSs vs. location of the clients, can also bekept by the DPA and used for the translation above.

An embodiment of the present invention allows HSS and/or HLR redundancyboth in scenarios comprising SLF and in scenarios not comprising SLF,and is usable for monolithic or tiered HSS architectures.

The DPA of the invention can be provided with standardized Diameterredundancy procedures towards the clients, thereby allowing deploymentof a plurality of DPAs, which provide a high availability ofcommunication between clients and destination hosts. Further, nomodification is necessary in Diameter clients (e.g. CSCFs) or Diameterservers (e.g. HSSs), as the novel processing carried out by the DPA actsonly at the “Diameter” level, and not at application level (e.g. CX-intfrelated processing).

It will be appreciated that operation of one or more of theabove-described components can be controlled by a program operating onthe device or apparatus. Such an operating program can be stored on acomputer-readable medium, or could, for example, be embodied in a signalsuch as a downloadable data signal provided from an Internet website.The appended claims are to be interpreted as covering an operatingprogram by itself, or as a record on a carrier, or as a signal, or inany other form.

The invention claimed is:
 1. A method of enabling redundancy for a HomeSubscriber Server (HSS) of an Internet Protocol (IP) MultimediaSubsystem (IMS) with redundancy being provided by a plurality of HSSinstances, where the data for each of a plurality of users is stored bymore than one of the HSS instances, the method comprising: arranging fora client node of the IMS to be provided with details of a proxy HSSrepresenting the HSS instances in response to an inquiry from the clientnode, the details including a destination host Attribute Value Pair ofthe proxy HSS; and the proxy HSS: selecting an appropriate one of theHSS instances to handle a request received at the proxy HSS from theclient node to obtain a selected HSS instance, the request including thedestination host Attribute Value Pair of the proxy HSS provided to theclient node; changing the destination host Attribute Value Pair receivedin the request based on the selected HSS instance; and forwarding therequest to the selected HSS instance for handling.
 2. The method inclaim 1, further comprising, a Subscription Location Function (SLF)being provided in the IMS, arranging for the SLF to provide the clientnode with the details of the proxy HSS.
 3. The method in claim 1,further comprising, a Subscription Location Function (SLF) not beingprovided in the IMS, arranging for the proxy HSS itself to provide theclient node with the details of the proxy HSS.
 4. The method in in claim1, wherein a Diameter protocol is used for communication between theclient node and the proxy HSS.
 5. The method in claim 1, whereinredundancy of the proxy HSS is provided, by having a plurality of proxyHSS instances, with redundancy towards the proxy HSS instances beinghandled by standard Diameter protocol mechanisms.
 6. The method in claim1, wherein at least some of the HSS instances are different respectivefront ends to a database.
 7. The method in claim 1, further comprisingmaintaining information at the proxy HSS for use in selecting theselected HSS instance.
 8. The method in claim 7 wherein the informationcomprises at least one of: information relating to respective loadsbeing experienced by the HSS instances; respective availabilities of theHSS instances; and respective status of the HSS instances.
 9. The methodin claim 7, wherein the information comprises geographic informationrelating to a plurality of sites.
 10. The method in claim 1, furthercomprising monitoring a state of each of the HSS instances for use inselecting the selected HSS instance.
 11. The method in claim 10, furthercomprising monitoring the state by using Diameter messages.
 12. Themethod in claim 11, further comprising monitoring the state by usingDevice-Watchdog-Request/Device-Watchdog-Answer (DWR/DWA) messages. 13.The method in claim 1, wherein selecting the selected HSS instance isbased on at least one of geographical location, availability, load, andresponse time.
 14. The method in claim 1, wherein the proxy HSS is anode of the IMS.
 15. The method in claim 1, wherein the proxy HSS is aDiameter proxy agent.
 16. The method in claim 1, wherein the client nodeis a Diameter client.
 17. The method in claim 1, wherein the client nodecomprises at least one of: an Interrogating Call Session ControlFunction of the IMS; a Serving Call Session Control Function of the IMS;an Aggregation Proxy of the IMS; and an Application Server of the IMS.18. An apparatus for enabling redundancy for a Home Subscriber Server(HSS) of an Internet Protocol (IP) Multimedia Subsystem (IMS) withredundancy being provided by a plurality of HSS instances, where thedata for each of a plurality of users is stored by more than one of theHSS instances, the apparatus comprising: means for arranging a clientnode of the IMS to be provided with details of a proxy HSS representingthe HSS instances in response to an in from the client node, the detailsincluding a destination host Attribute Value Pair of the proxy HSS; andmeans for arranging for the proxy HSS to: select an appropriate one ofthe HSS instances to handle a request received at the proxy HSS from theclient node to obtain a selected HSS instance, the request including thedestination host Attribute Value Pair of the proxy HSS provided to theclient node; change the destination host Attribute Value Pair receivedin the request based on the selected HSS instance; and forward therequest to the selected HSS instance for handling.